Thanks for working on this! I'll need more time to fully review this, but at a first glance this looks like a good direction.

• The futex syscall treats one of its arguments as either a nullable *const Timespec or a u32, depending on the context. The futex_time64 fallback to futex_old uses NOSYS as its deciding factor, which can also be generated in other ways. This may lead to futex_old dereferencing an invalid pointer (because it is null, or not a pointer in the first place). As we now have different entrypoints that know whether the value should be a nullable pointer or a u32, I would suggest splitting up the backend futex functions into two variants (each) with different signatures. This would prevent a fallback to futex_old happening when the argument is not a pointer. Adding the null check is then trivial.

This sounds like a good idea to me.

• There are two flags that may sometimes change the function behavior. The first flag, FUTEX_PRIVATE_FLAG basically just says whether the lock(s) are guaranteed to be process-private (for some kernel optimizations). It is available for every single function. The second flag FUTEX_CLOCK_REALTIME changes how the timeout is interpreted in a few functions. Removing those flags by way of introducing more functions is viable, but I am unsure if it really makes sense to add that many more functions. Since their meaning is very different, I would suggest splitting them into two enums (FutexPrivacy::Shared and FutexPrivacy::ProcessPrivate, and FutexClock::Realtime and FutexClock::Monotone) and making them two arguments. It might even make sense to take them as compile time parameters. What do you think?

Could you say more about what the advantage of this would be over the current FutexFlags approach?

• There are (already) a lot of functions. Instead of having them be global functions, there could be a struct Futex<'a>(&'a AtomicU32); (and similarly FutexPI), which then could show only the functions applicable to that scenario. E.g., Futex(&word).cmp_requeue(...) and FutexPI(&word).cmp_requeue(...) would call futex_cmp_requeue and futex_cmp_requeue_pi respectively without polluting each other's namespace. While this would make the API a bit nicer, I fear it would suggest that it does more than just the syscalls. What do you prefer?

I like how global functions makes it clear that they're "just functions"; as you say, it also feels like a wrapper type might suggest it does more. For namespacing purposes, what if we created a new pub mod futex and put all these new functions in it? Perhaps we could even drop the futex_ prefix from them, so users could do futex::wait instead of futex_wait.

• While I have not done so right now, it should be possible to retain the old futex API, so as to be semver compatible - ideally with a #[deprecated]. Would this be important to you? If so, should FutexOperations be retained in a way that does not add any new variants?

Yes, I think it would be good to retain the old API and remain semver-compatible. A #[deprecated] makes sense to me too. I don't have an opinion about whether to hide new variants in FutexOperations.